collection

2. CalDAV Testing

During CalDAV testing, the following things were noted:

When creating a new single-instance meeting with an alarm set to trigger 15 minutes prior to the schedule time of the meeting, a server removed the alarm after several update operations.

When modifying the location of the meeting a server did not preserve seconds on the override of the meeting.

After modifying the title of the first instance of the recurring meeting a server did not support the overwrite.

On the “Query all components and return ETag WebDAV property and all data” test, a CalDAV client did a query only for the etag, not the calendar data

When creating a calendar-query REPORT, one server’s Reports are overridden in separate resources with the same url.

After creating a new calendar in the current user’s personal calendar space, one CalDAV server appends “1” to the name of the created folder.

A CalDAV server verified an issue that makes it impossible to use alerts in one of the clients. Fixing the problem will require the server vendor to preserve non-standard properties specific to this client, so they do not have a complete resolution at the moment. A few other minor issues were also uncovered.

This same server discovered that they were missing a CalDAV operation (options request, not currently invoked by any other client). They implemented a fix during the interop and verified that the basic scheduling features worked after adding support for the options request. They helped one of the clients testing iCalendar uncover an issue with regards to incrementing sequence numbers when canceling events.

One CalDAV server noted that they found CalDAV implementations seems more mature than before. Items they noted were GUI and Usability issues in Availability settings in one of the clients. They noted incorrect server responses that caused problems with another client.

A CalDAV server noted the following issues within their own application:

  • a problem with xmlns:D="DAV:"

  • another problem with DAV: in iSchedule response

  • Originator and Recipient address are swapped when a meeting reply was sent from a server over iSchedule

  • finally it works.

Issues found with other clients and servers:

  • iMIP: iPhone doesn’t recognize meeting invitation from a CalDAV server

  • A CalDAV client modified structure of MIME format on site

  • iMIP: when meeting is accepted in a server’s email, reply is sent to From: header address instead of Organizer’s address.

One CalDAV server noted that all Tomcat versions don’t work with large data amounts with CalDAV. They also noted that a client stored user credentials in the browser cache and even if the server deleted a calendar account and added it back it didn’t ask them to re-authenticate. Also, upon deletion, we had to clear the browser cache to clear user credentials. This happened on Internet Explorer and Firefox.

A CalDAV server noted the following:

Problems found:

  1. If you use the wrong authentication for a valid Calendar, we give a 501 error. A more friendly response would be desirable.

  2. If you add a daily recurrence with one of the clients with four instances and delete the third instance, you lose sight of the fourth instance too.

  3. If you have a recurrence with an exception where the start of the recurrence specifies seconds, we generate a bad recurrence-id for the exception.

  4. We were not preserving the value of RSVP in Meeting REQUESTs. i.e. we always assumed the value was TRUE.

  5. Notes originated meetings were not visible to our CalDAV clients.

  6. One server’s iMip Gateway originated messages are not recognized as meeting requests by us. We spotted an original issue that the Content-Type METHOD parameter was not being specified but we still had an issue with the final form of Mime structure that they intend to use.

  7. Notes originated requests end up with blank DESCRIPTION in the iCalendar object and invalid ATTACH properties.

Another server observed the following during testing of iSchedule.

  • From one server to another server, they got the invitation ok, and reply sent properly and the client was updated with the status

  • From one server to another an invitation doesn’t show up on the client

  • From one server to another the invitation was received ok, and reply sent properly, and they could see status updated in the client

  • On another server to server, the invitation was received ok, and reply sent properly but the status was not updated on the client

  • From one server to another server, the invitation was ok, but reply can’t be sent properly

  • From one server to another, the invitation was ok, but reply can’t be sent properly

One server noted:

There were a number of fixes needed to new code — mostly in CalDAV scheduling — had a number of interactions with a server with problems at both ends.

One server tested with a client and found it worked well enough with the new CalDAV scheduling draft.